Tag: programming languages

In my various efforts to develop new programming languages, I’ve occasionally looked sidelong at linear types, as something that looks like it could be really useful if it wasn’t so incredibly cumbersome.

And now some folks have come up with a way to make them much easier to use[^1]! Or at least that’s the hope. This past week I’ve been trying to implement their execution model into a new programming language, to get a feel for what it’s like to actually use. Check out my field notes, if you’re already familiar with the paper.

For an overview of the paper this is based on, check out this post.

Here are my notes about trying to implement a linear/flow language in typescript, compiling to javascript. It uses runtime checks to enforce lienarity; so far there is no type checker.

Update 2025: “The haters said I couldn’t do it. And they were correct. Honestly great call from the haters.” 😄 yeah so I tried implementing this, and was in fact a bad user experience.

What if type inference felt like a real-time conversation, instead of emailing code back and forth?

With type inference, compilers are faced with a difficult task: intuiting what types a user had in mind (but didn’t write down) while writing some code. It all falls apart when the types that the algorithm assigns are different from those the user expected, and especially so when the type error reported is far away from the site of mental mismatch.

Unison is doing a lot of interesting things, and as I recently implemented an alternative runtime in rust, I have some insight into what’s going on under the hood 😉. Here’s my attempt to sum things up.